Many entities employ computer networks to process and store data. As the size of a network increases, the heterogeneity of the network typically also increases. This heterogeneity can result from a lack of a unified network growth plan, the fact that only particular applications are available for particular platforms, budgetary constraints or other constraints. While the heterogeneity in a particular network may have arisen based on practical concerns, it can lead to difficulty implementing applications that require distributed processing and/or the distribution of commands to multiple platforms.
FIG. 1 illustrates an embodiment of a prior art network that employs a command server 100 connected to a Unix system 105 and a Windows system 110 (Windows is a trademark of Microsoft Corporation of Redmond, Wash.) via a communications network 115. Command server 100, Unix system 105 and Windows system 110 can each include processors, memories, network interfaces or other computer components known in the art. In order to issue a remote command to Unix system 105 and Windows system 110, the command server 100 is, in typical prior art systems, required to format the command separately for each of Unix system 105 and Windows system 110. Based on the command, Unix system 105 and Windows system 110 could perform a process and return results.
FIG. 2 illustrates a prior art software architecture for issuing and processing commands. Command server 100 can include a command issuing program 200 that can issue commands to Unix system 105 (e.g., command 202) and Windows system 110 (e.g., command 203). Each of command 202 and command 203 can include a command string and environmental or working variables that are specific to each system. Additionally command 202 and command 203 will be formatted in a manner that can be used by underlying Unix system 105 and Windows system 110. Because each command is going to a different platform, command 202 and command 203 can contain different command strings, working variables and/or formats.
At Unix system 105, an interface program 205, such as an Internet Daemon (e.g., inetd or xinetd) can spawn an instance of a system shell 210 (i.e., the outermost layer of a program such as an operating system). Typically, the system shell to be spawned is stored in a configuration file. System shell 210 acts as an interface to underlying processes (e.g., shell process 215) that execute the received command and can provide a user interface for the underlying program. After verifying that command 202 is a valid command, system shell 210 can pass the command to shell process 215 for execution. The results of the execution are then passed back to the command issuing program via system shell 210 and interface program 205.
Similarly, at Windows system 110, an interface program 220 can receive command 203 and spawn system shell 225. As would be understood by those of ordinary skill in the art, Windows based systems do not typically include an inetd type of network service. Therefore, custom inetd type services are typically provided. After verifying the command 203 is valid, system shell 225 can pass the command to shell process 230 for execution. The results of the execution are then passed back to the command issuing program 200 via system shell 210 and interface program 205.
The typical interaction in prior art systems occurs as follows: the command issuing program opens a TCP/IP socket to the computer system receiving a command, the inetd or other interface program spawns the appropriate shell, the command issuing program issues a platform specific command to be executed, the command issuing program reads the response data back from the shell process and closes the TCP/IP connection.
Prior art systems suffer several shortcomings. As an initial problem, access control is extremely limited. Typically access is controlled through a user account setting in an inetd configuration file. If a command is received from an account with access, the inetd file will spawn the shell. No password based authentication is required. Thus, a user using the correct account name can access a computer system's shell without requiring a password. The user can then issue commands to the shell for potentially malicious purposes.
As a second shortcoming, different platforms require different working variables. For example, Unix requires different working variables than Windows, and some Unix shells require different working variables than other Unix shells. Dynamic construction of the working environment at a particular computer system must typically be supplied as part of the executed command. If the same command is provided to different platforms, the command will have to be constructed separately to account for differences in working variables used by each platform. For example, command issuing program 200 must create command 202 to include working variables that can be used by shell 210 and create command 203 to include working variables that can be used by shell 225. Since shell 210 and shell 225 operate on different platforms (e.g., Unix versus Windows) the construction of each command may be significantly different. This leads to a high level of complexity in the construction of commands and corresponding complexity in the programming of command issuing program 200.
Moreover, in prior art systems, the shell will typically have a default directory in which a command runs. To change the initial working directory, the initial working directory must be specified in the command. Because each platform uses different directory structures, a command will have to include the initial working directory in a format understandable by the specific platform to which the command is directed.
Prior art systems suffer several additional shortcomings. For example, process exit status (e.g., whether an underlying shell process has completed execution of a command) is not typically available to the command issuing program. Additionally, error reporting is inconsistent across platforms and may not be provided by some platforms. As yet another disadvantage, the data returned by most shells is raw command output. Therefore, the command issuing program must be able to interpret the data based on the commands issued and the platforms responding.